\documentclass[a4paper,11pt]{report}
\usepackage{graphicx}
\usepackage{multicol}
\usepackage{hyperref}
\usepackage{wrapfig}
\usepackage{url}
\usepackage[right=1.5cm,left=2.5cm,top=2cm,bottom=2cm]{geometry}

\DeclareGraphicsExtensions{.pdf,.png,.jpg}

\begin{document}
\author{\textbf{Group 04}\\L. van Dijk\\ G. Mulder\\ L. van Oostveen\\ J. van der Waa}
\title{Kenny Geeststorm\\
\small{Course Robotics 2009-2010, L. Vuurpijl, Radboud University Nijmegen}
\includegraphics[width=18cm]{schematic}
}
\date{July 5, 2010}

\maketitle \tableofcontents \listoffigures
\pagebreak


\chapter{Introduction}
Kenny Geeststorm, or shortly: ``Kenny'', is the name of the robot our team created for the Robotics course. He has been named after a character in \emph{South Park}, an American animated sitcom which is known for its strong language and four main characters. One of these characters is called Kenny McCormick. He dies in almost every episode in various (extreme) ways. During the development of ``Kenny'', he has been dissected, modified, reassembled, had his brains (\emph{the Brick}) transplanted more than once, was dissected and modified, over and over again.

This stubbornness and general lack of cooperation from out robot (perhaps nominatively determined) has haunted the entire process, including during the tense five minutes before ``Kenny'' had to be demonstrated. This report includes a section devoted to this Demo day, or destruction day as some of the group members called it.

Its `brain' is based on the LEGO Mindstorms NXT 2.0 Brick and it uses various sensors and actuators to act and react to stimuli in its environment. The Brick is equipped with several input and output ports: there are four input ports (used for sensors) and three output ports (used for actuators, such as motors).

This report contains several topics related to the building and development process of Kenny. Among these topics are \emph{ecological niche}, \emph{behaviours and layers}, \emph{design considerations} and \emph{implementation details}.\\

The \emph{ecological niche} topic reports several details about the \textsf{modus operandi}. This can be seen as the environment in which the robot resides, the obstacles it might encounter and what to expect in general. In order to design a robot, it is necessary to know in what kind of environment it is going to operate.\\ 

\begin{wrapfigure}{r}{10cm}
\vspace{-20pt}
\includegraphics[width=10cm]{puppet}
\caption[``Kenny'''s Head]{Photo of ``Kenny'''s head.}
\end{wrapfigure}

In \emph{design considerations}, various aspects of the robot's design philosophy will be discussed, along with several problems encountered during the building phase.


\chapter{Ecological niche}
\label{ch:niche}

What is our robot's ecological niche? Even though there probably will be a lot of resemblances between our robot and the other team's designs, our robot is quite unique in both physical and software design. \\

``Kenny'''s perception of the world around him stems from one main principle: avoiding obstacles in its path. To make sure our robot would not end up ramming a wall until someone would do the merciful thing, we gave our robot a pair of motors to manoeuver and an ultrasonic sensor to be able to detect obstacles in front of it. \\ The ultrasonic sensor has, however, an inherent flaw: it can only detect obstacles present in a narrow cone in front of the robot. For all our purposes this will suffice, but if our robot were to be put in the vicinity of a series of obstacles just to the side of the robot, it would in all likelihood drive into them and get stuck with no hope of escape, apart from random motion. \\

We also equipped ``Kenny'' with a rear-mounted light sensor, in order to detect and avoid obstacles behind our robot. This sensor only reacts to the amount of light reflected back to it, and is normally used to detect black and white lines. We used the basic knowledge that more light is reflected back from an object closer to the robot to bodge together a basic collision avoidance program, and added it to the main avoid task. \\

Our robot's third, yet most important sensor is the colour sensor. This sensor will return the colour of the surface it is aimed at, if the surface is in range of the sensor. Using this sensor enables our robot to `see' what material it is crossing, or what it encounters on its journey. This enables it to detect objects and their colours, and thus move the coloured victims to the correct hospital. The sensor also enables Kenny to recognize coloured paths, and let it decide whether to follow the line, or ignore it.

\begin{wrapfigure}{l}{7.5cm}
\vspace{-10pt}
\includegraphics[width=7.5cm]{firstdesign}
\caption[First design]{Photo of (perhaps) the first design of Kenny.}
\end{wrapfigure}

And so ``Kenny'' perceives the world using three sensors. It detects objects in front of it and behind it in time to avoid them, while constantly checking what kind of material it is moving on. \\

``Kenny'' is a robot who uses its sensors based on the single principle that preventing collisions is easier than fixing them. Especially in a world completely alien to the robot, apart from the data is acquires itself.



\chapter{Behaviours and layers}
\label{ch:behavlay}
This chapter deals with the robot's behaviours (e.g. bringing a victim to the hospital), how these behaviours are split up in layers (e.g. following a line) and what the interaction of these layers is.

\section{Behaviours}
\label{sc:behav}
``Kenny'' has to deal with various circumstances in his environment, which are described in \autoref{ch:niche} \nameref{ch:niche}. 

Given these circumstances, the robot should show a certain behaviour. These behaviours have been programmed according to the \nameref{ssc:react}.

\subsection{Reactive paradigm}
\label{ssc:react}
A paradigm in Robotics is a technique which describes in which way the basic principles of \emph{Sense}, \emph{Plan} and \emph{Act} are communicating and how these are organized. The reactive paradigm only uses \emph{Act} and \emph{Sense} and these two are directly connected to each other. To put it simply, something is sensed and immediately an appropriate action is taken.

``Kenny'' has multiple Sense---Act processes. A combination of these processes (or \emph{layers}) gives a certain behaviour, which will be explained in the following sections.

\subsection{Exploring the environment}
\label{ssc:explore}
Considering the possibility that the robot can be put anywhere in the arena, it is desired that the robot can discover its surroundings on its own, prevent colliding with walls and safely conduct the victims to an appropriate hospital.

\subsection{Finding victims and getting to the hospital}
\label{ssc:victims}
Next to exploring the environment, the robot must be able to detect victims. There are 2 types of victims that need to be recognized: victims with severe burns and victims requiring Intensive Care. The \emph{burn victims} are represented as \textbf{red} balls whereas \emph{IC victims} are represented as \textbf{blue} balls.

When a victim is found, it should be brought to the appropriate hospital. The robot should find its way to the path leading to the hospital. Once the path is found, it should follow this line until arrived at the hospital and subsequently release the victim.

\section{Layers}
\label{sc:lay}
This section is devoted to the several layers in ``Kenny'''s brains.

\subsection{Avoid}
\label{ssc:avoid}
The avoid layer is, in a sense, the most important layer. This layer is programmed to sense objects which need to be avoided. For example, if ``Kenny'' is heading towards a wall, a sensor should detect this wall and take appropriate action. The appropriate action is to make an evasive movement, in order to prevent a collision with the wall. Furthermore, this layer should be constantly active, unless another task requires it to be temporarily halted. 

\subsection{Wander}
\label{ssc:wander}
Together with the \emph{Avoid layer}, the Wander layer is responsible for \emph{exploring the environment}. The Avoid layer prevents collisions, while the Wander layer takes care of moving around in the environment. This can be done in a very complex way; by moving around and creating a map of the environment, or in a simpler way; by picking a random direction, moving in that direction for a while and picking another direction.

\subsection{Ball search and capture}
\label{ssc:ballz}
Another task is finding victims. The corresponding layer for this behaviour is \emph{ball search}. While the robot is wandering, this layer checks the current colour detected by the colour sensor. If either a red or a blue colour is detected (respectively a red or blue ball), the claw is lowered to capture the ball. When completed, the ball search is stopped and \nameref{ssc:follow} takes over.

\subsection{Line search and follow}
\label{ssc:follow}
When a victim is captured, this layer uses the colour sensor to detect specific colours which correspond to a line. As soon as a correct colour is found (i.e. a line has been detected) the searching stops and the following starts. Line following looks a lot like wandering, however, it limits the movement of the robot by constantly checking for a line.

\begin{wrapfigure}{c}{10cm}
\includegraphics[width=10cm]{modifying}
\caption[Modifications]{Modifying Kenny.}
\end{wrapfigure}


\chapter{Design considerations}
\label{ch:design}
One of the most important things our team had to do was think about every step in our robot's design before actually implementing it. Even with our slightly anarchistic design philosophy several considerations were made.

\section{Flexibility} A search-and-rescue robot should be as flexible as possible, in order to survive in a hostile environment. For example, it should not rely on a fixed route, or be able to get stuck on an `easy' obstacle. In order to maximize our robot's flexibility, we made both hardware- and software-related design choices. \\

One of the choices we made was to make a rack-type mount for our Brick that would make it possible for us to quickly remove the Brick from the robot, in order to work on the robot and upload software at the same time. This coincidentally turned out to be a good idea later on, when our Brick crashed, since we could just remove the Brick from its mount, instead of disassembling the entire robot. 

\section{Robustness} 

Robustness is crucial for any search-and-rescue robot, since they will be sent into highly hostile environments. Even a simple Lego robot needs to have some degree of both hardware and software robustness: if it can lose a wheel when turning it will not move very far, and if it gets stuck in an infinite loop of some sort it will not be rescuing anything any time soon.

To make our robot as robust as possible we added a few tricks: software-wise, it has a decent chance to untangle itself from obstacles, due to it turning randomly even if it doesn't detect an obstacle with any of its sensors.

A hardware trick we implemented was a fair amount of ground clearance, even when the claw used to rescue victims is down. This prevents it from getting stuck on lines or the rubber tires used to hold victims in place in the arena.

\section{Operator Usability}

This might seem like something you would not normally take into account while designing a robot, but we decided that making our robot a pleasure to work on was worth a couple of design choices. 

The most important choice we made is probably the Brick mount, for reasons explained under \emph{flexibility}. Another choice was using a sturdy design that could be lifted with one hand, while still being able to resist a fair amount of tinkering.

\chapter{Implementation details}
\label{ch:implement}
During the development of ``Kenny'', one could never be certain whether the robot would look, behave or smell the same one week later. On the one hand, this was caused by our `slightly anarchistic design philosophy', on the other hand, ``Kenny'' fell apart quite often, could not handle the stress or parts were simply not fit for its purpose. The chassis was not the only part of the robot that got multiple treatments; our group probably had the Brick replaced more often than any other group.

\section{Chassis}
\label{sc:chassis}
\begin{wrapfigure}{r}{5cm}
\vspace{-20pt}
\includegraphics[width=5cm]{modify2}
\caption[Modifications, again.]{Photo of yet some more modifications.}
\vspace{-30pt}
\end{wrapfigure}
``Kenny'''s chassis was completely built from scratch. After that, he was taken apart and reassembled again. Multiple times. Some group members already had experience with building Lego robots. Very quickly, a first design was built and the robot slowly developed. It was a challenge to, given the limited pieces available, build a robust yet efficient and flexible robot. Nearly every week, ``Kenny'' was taken apart and a new chassis was built. Every adjustment was made by matter of improvisation and former experiences.

\section{Actuators}
\label{sc:actuators}
By default, there is room for three actuators. In our implementation, all three actuators were used (three motors). We used two motors for propulsion and one for \emph{The Claw} (see below). The two motors for propulsion each had its own wheel to drive. This meant that ``Kenny'' could turn very quickly and `on the spot', by letting one motor turn forward and the other backward. For extra stability, two smaller wheels were attached at the back of the chassis, in order to prevent tilting and/or flipping over.

\subsection{The Claw}
\label{ssc:the_claw}

\begin{wrapfigure}{l}{5cm}
\vspace{-15pt}
\includegraphics[width=5cm]{claw}
\caption[The Claw]{Photo of an early version of ``Kenny'''s Claw.}
\vspace{-40pt}
\end{wrapfigure}
\emph{The Claw}, similar to the chassis, has known various implementations. One of the earliest designs was a single arm attached to a motor, yet it was quickly replaced with a double arm (forming a `cup' around the ball). Tests showed, unfortunately, that this did not work as desired. The cup was resituated in the middle and improved with a V-like shape (attached to the chassis) near the ground to guide the balls into \emph{The Claw}. Our final design proved to be efficient, yet simple. The cup was enlarged to the width of the robot and the V-like shape became redundant.



\section{Sensors}
\label{sc:sensors}
What good is a robot if it cannot sense the world around it? Although there were four sensor ports, we only used three sensors: a colour sensor, a light sensor and an ultrasonic sonar.

\subsection{Hi-Technic Colour sensor}
The colour sensor has been used in multiple situations. It was used for ball detection and line following. The sensor was placed in such a way that it could detect a ball, and after that, be re-used as instrument for line following. Various readout methods have been used, although not all represented colours in a favorable way. Having tried using RGB values as sensor values, the colour numbers proved to be exact and stable enough for colour detection. In combination with weird sensor values, different firmwares on the various Bricks we have used and the random \textsf{File error}s on these Bricks, the colour sensor has officially been awarded Most Annoying Sensor Ever. 

\subsection{Light sensor}
Object avoidance was taken care of by, on the one hand, the light sensor and, on the other hand, the sonar. The light sensor was used to detect objects at the back of ``Kenny'', in terms of reflected light.

\subsection{Ultrasonic sonar}
In combination with the \emph{Light sensor}, the ultrasonic sonar took care of objects appearing in front of ``Kenny''. It was placed directly above the \emph{Colour sensor}, at the front of the robot. The sonar produces high-frequent sounds and measures the time it takes to send, reflect and return those sounds. It had a fixed position, i.e. it did not turn separately from the robot as a whole. This limited its range to objects situated directly in front of the sonar (as we experienced on the Demo day, explained in \nameref{sc:dem_avoid}).

\section{Brick placement}
\label{sc:brick}
The Brick was placed in such a way that it could be easily removed from the chassis. Besides that, the four sensor- and three actuator ports were directly accessible, as well as the USB port (for programming purposes) and the charger input. This modularity turned out be very useful, given the problems with various Bricks we have used.

\subsection{Connections}
For the record, the following connections were used on the Brick:\\
\begin{tabular}{ | l | c | c | l | l | }
\hline
Port & Input & Output & Alias & To \\
\hline
1    &   X   &        &   S1  & Hi-Technic Colour Sensor \\
2    &   X   &        &   S2  & Light sensor \\
3    &   X   &        &   S3  & NOT CONNECTED \\
4    &   X   &        &   S4  & Ultrasonic sonar \\
\hline
1    &       &   X    & OUT\_A & Left driving motor \\
2    &       &   X    & OUT\_B & The Claw \\
3    &       &   X    & OUT\_C & Right driving motor \\
\hline
\end{tabular}

\chapter{Demo day}
\label{ch:demo}
One day before the demo day, in the afternoon, a strange bug appeared. The NXC code compiled correctly, yet it gave a \textsf{File error} on the Brick. Even when an older version of the code was put on the Brick, it gave the same error, although it had worked beforehand. A lot of effort was put into solving this rather nasty error (next to the fact that the error message ``\textsf{File error}'' is very non-descriptive). It took until 20 minutes before the actual demonstration when the underlying problem was found.

There is a certain technique to read the RGB values from the colour sensor. Since these values were not constant enough, the readout method was changed back to `normal', namely \emph{colour numbers} ranging from 0 up to and including 17. The method used to read the RGB values also included this colour number and this same method was used to read the \emph{colour numbers}:
\begin{verbatim}
if (ReadSensorHTColor(S1, num, rood, groen, blauw))
{
    // rest of the code
}
\end{verbatim}
whereas \textbf{S1} is a constant referring to the \emph{sensor port} of the colour sensor, \textbf{num} is the colour number and \textbf{rood}, \textbf{groen} and \textbf{blauw} are respectively the RGB values for \emph{red}, \emph{green} and \emph{blue}. These last three variables were since then never used again. The \textbf{num} variable, however, was used for working with colours. Furthermore, the \textsf{ReadSensorHTColor} method is in an \emph{if statement} because this method returns a \textsf{boolean} on success (true) or failure (false).

This readout method had been working perfect until D-1 (the day before Demo day). It then worked again for a moment and in the morning of Demo day, it failed again. Given the fact that it compiled and had worked correctly, it took a very long time to find out this was the reason for the infamous \textsf{File error}.

Every occurrence of this method was changed, last-minute, into 
\begin{verbatim}
int num = SensorUS(S1);
\end{verbatim}
Since this change was made on such a short notice, there was not enough time to check each value and properly test the robot to see if these were correctly read. The \emph{line follow} method was probably affected most by this change, since it was built around the old \textsf{ReadSensorHTColor} method. There is a possibility that this method of reading sensor values is slower and/or that the colour numbers do not correspond or are slightly different. When the \textsf{ReadSensorHTColor} was used as basis for line following, it worked perfectly.

\section{Wander}
\label{sc:dem_wander}
During the Demo day, the robot would not move in a straight line, but mostly drove around in circles. To quickly solve this bug in a short amount of time, something was changed in the \emph{wander layer}:

Following is the \emph{wander layer} code as used at the beginning of the Demo day:
\begin{verbatim}
task wander()
{
    while (true) {
        if (do_wander)
        {
            Acquire(motorMutex);
            OnRev(OUT_AC, MOTORSPEED); // drives straight for
            Wait(Random(125)+250); // a random amount of time
            int a = Random(2);
            if (a == 1) {
                Off(OUT_A); // turns to the left
                Wait(Random(250)+250);
                Release(motorMutex);
            } else if (a == 0) {
                Off(OUT_C); // turns to the right
                Wait(Random(250)+250);
                Release(motorMutex);
            }
        }
    }
}           
\end{verbatim}
which caused the robot to drive straight ahead for a very short amount of time and make a turn.
The first \emph{Wait} statement used to look like this: 
\begin{verbatim}
Wait(Random(125)+2500);
\end{verbatim}
This wait-statement was modified in a quick pit stop, after which the robot did not turn nearly as often as it previously did. We still have not figured out how a blatant mistake like a broken wait-timer ended up in our code.


\section{Avoid}
\label{sc:dem_avoid}
From time to time, ``Kenny'' collided with objects or walls during the Demo day. The cause of these collisions can be found in the design of the robot. The ultrasonic sensor is situated at the front of the robot, in order to correctly detect obstacles that should be evaded. The downside of this design was revealed on the Demo day. Below, you can find a schematic drawing of the way ``Kenny'' can collide with an object without having `seen' it.
\begin{figure}[h!]
\includegraphics[width=15cm]{demo_collision}
\caption[Colliding with an object at an angle]{Schematic drawing of ``Kenny'' colliding with an object without having `seen' it.}
\end{figure}

Given the limited range and viewing angle of the ultrasonic sensor, it can only detect objects when they are directly in front of the sensor. If ``Kenny'', for example, drives towards a wall in a certain angle, the wall is not detected by the ultrasonic sensor, because it is out of range.

This could have been solved in various ways. First of all, the body of ``Kenny'' could have been made smaller, in such a way that it has a smaller chance of hitting walls or objects. This is, however, quite difficult, since the Brick is wider than the ultrasonic sensor.

Secondly, another option, which was implemented on a robot from another team, lets the ultrasonic sensor turn (i.e. let it look from left to right and back). The viewing angle of the sensor increases and the chance of collision decreases. One of the  downsides of using this method is that each team only has three motors available for use in their robots. ``Kenny'''s third motor was used to raise and lower its claw. In order to use this method, the claw had to be raised and lowered in a different way. 

Finally, as a possible last resort, the robot could have been programmed to turn to its left and right every once in a while, in order to detect objects which could not be detected by viewing ahead.

\section{Positive aspects}
\label{sc:dem_positive}
Even though some things did not go according to plan, there was one task that our robot performed admirably well: grabbing and releasing the \emph{patients}. Given the design of the claw in combination with the underlying code, it was very difficult to miss a patient.

When the colour sensor detects a patient (a red or a blue ball), the robot drives forward while the claw is lowered simultaneously. The purpose of the lowered claw is only to hold the patient, not to `capture' the patient. This technique prevents the claw from pushing the patient away from the robot or keeping the patient in a deadlock between the claw and the ground.
\begin{figure}[h!]
\includegraphics[width=15cm]{demo_capture}
\caption[Process of saving a victim]{Three stages of saving a victim: 1) detecting a ball, 2) moving forward whilst lowering the claw and 3) holding the ball}

\end{figure}

Another thing that went very well is the releasing of the patient in the correct hospital. As soon as a line was found, the robot constantly checked whether there was a wall in front of it. If this was the case, the patient was \emph{released}. Quite simple, yet very effective.

\section{Conclusion}
\label{sc:demo_conclusion}
The demonstration did not go according to plan. One of the main reasons was that the colour sensor returned different numbers than the ones it returned in tests. It still remains a mystery why it worked one day and failed miserably the other day. Besides that, the \emph{avoid} part did not function correctly with the design. Fortunately, the capturing and releasing of the patients went perfectly!

\chapter{Wrapping up}
\label{ch:whopper}
This document has been made possible with \LaTeX.\\
``Kenny'' can be found on several spots on the Internet:

\begin{tabular}{ r |l }
 \textbf{Facebook}    & \url{http://facebook.com/kenny.geeststorm} \\
 \textbf{Twitter}     & \url{http://twitter.com/Killarobat} \\
 \textbf{Google Code} & \url{http://code.google.com/p/geeststorm/}
\end{tabular}

\emph{Google Code} contains a few Wiki pages and the complete Subversion repository. \emph{Twitter} contains some status updates (unfortunately, ``Kenny'' was not able to tweet anything) and \emph{Facebook} contains some pictures.

\begin{center}
\textit{Some say, he secretly climbs out of his box at night, and that obstacles avoid \textbf{him}}.\\
All we know is that he's called Kenny!\end{center}

\begin{wrapfigure}{l}{15cm}
\vspace{-10pt}
\includegraphics[width=15cm]{final}
\caption[Final design]{Photo of Kenny's last appearance.}
\end{wrapfigure}
\end{document}
